机场选购与测评

0. 一页结论

给你的配置建议（日常办公 + 全球多国）

合计约 50–100 元/月，其中主力不超过 60 元。任何"年付 ¥99 不限量"的选项直接跳过，不在讨论范围内。

1. 机场是什么

"机场"是中文圈对代理订阅服务商的俗称。它不卖软件，卖的是一条订阅链接：客户端定时拉取这条链接，得到一份节点列表（服务器地址、端口、协议、密码/密钥）和一套分流规则。换机场 = 换一条订阅链接，客户端不用重装。

它和另外两个概念必须分清：

图 1-1　用例图：机场选购与使用的行为全景（整体行为）

2. 一次请求的完整链路

看懂这张图，90% 的营销话术就失效了。你的每一次点击，走的是这样一条路径：

图 2-1　时序图：一次请求从客户端到落地（核心主流程）

三个关键节点决定了体验：

1. 第 4 跳（客户端 → 入口）：这一段走公网出境，是 GFW 主要识别和干扰的位置。协议抗不抗封锁，看这里。
2. 第 5–6 跳（入口 → 落地）：这一段是"中转"还是"专线"。专线走运营商内网，不经过公网国际出口，晚高峰不跟别人抢带宽——这就是专线溢价的全部来源。
3. 第 7 跳（落地 → 目标站）：这一跳的 IP 决定了流媒体解锁、AI 服务可用性、账号风控。线路再好，落地 IP 脏，ChatGPT 照样封你。

3. 线路类型：直连 / 中转 / 专线

这是决定价格和晚高峰体验的唯一变量。所有"高端""企业级"的宣传，最后都要落到这张表里的某一格。

图 3-1　活动图：机场选购决策流程（含硬性排除与验收分支）

唯一的量化判据：晚高峰衰减率

衰减率 = (平峰下载速度 − 晚高峰下载速度) / 平峰下载速度 × 100%

真专线        < 10%
专线+中转混合  10% – 15%
公网中转/直连  > 20%（常见 30%–60%）

测法：同一节点、同一测速服务器，下午 14:00 左右测一次，晚上 21:00–22:00 测三次取平均。只看晚高峰那一次的人，都会被白天的数据骗。

4. 选型决策流程

把上面的知识变成可执行的动作。整个流程只有四步，其中三步是"排除"而不是"挑选"。

4.1 硬性排除（不做这步，后面全是浪费）

4.2 候选收集

从榜单站、社区、TG 群收集 3–5 个候选名字（只取名字，不取结论）。记录四件事：运营起始年份、最低月付价、标注的线路类型、标注的落地国家数。

4.3 短周期试用

买最短周期：月付，或按量小包（1–3 元体验包）。目的不是"用"，是"测"。同时导入客户端，确认兼容 Clash / sing-box / Shadowrocket 三种订阅格式。

4.4 七天验收

跑完第 10 章的 SOP，填完第 7 章的评分卡。达标续费，不达标淘汰。整个决策周期控制在 7–10 天，成本控制在 30 元以内。

5. 生命周期与跑路

机场不是"好"或"坏"，而是处在一个生命周期里的某个位置。绝大多数人在错误的时间点买入了错误的阶段。

图 5-1　状态机图：机场服务的生命周期（解释为什么不能年付）

5.1 跑路的五个阶段

5.2 五个高危信号

1. 反常大促：突然"充 100 送 150""终身不限时"。这是最后一次圈钱。
2. 群组全员禁言：阻止用户串联维权。
3. 工单停摆：平时 1 小时响应，忽然 3 天没人。
4. 核心节点大面积红灯超过一周：通常是欠费被上游停机。
5. 强制安装"专属客户端"：可能为了掩盖故障或植入后门。

6. 测评平台矩阵

这是本文最实用的一节。测评平台要分成两类用：工具型自己产生结论，榜单型只提供线索。

6.1 工具型：中立、可复现、结论可信

6.2 榜单型：全部有返利，只能当线索

这类站点靠推广佣金生存，页面上的"优惠码"就是收入来源。它们不是骗子，但它们的"排名"是商业排序，不是质量排序。

• jichangclub.co、pjc.mom、jichangp.world、yiyuan-jichang.org
• jichangyyds.com、ygjc.cc、jinqians.com
• jichangs.world、yp7.net（有风险监测页，相对透明）

正确用法：只从里面抄名字，然后回到 6.1 自己重测。看它有没有公开评分方法、有没有披露哪些是合作品牌、有没有写缺点——三条都没有的，连名字都别抄。

6.3 证据：同一家机场，三家给出三种定性

线路类型都能对不上，衰减率就更不可能对得上。这类数字的共同点是：你无法复现，也无法追责。

6.4 证据：价格本身自相矛盾

算一笔账：1000 个用户共享 500Mbps（月租约 1.2 万元），人均带宽成本就是 12 元/月，还没算落地机房、原生 IP、支付通道手续费（8%–15%）、防御和客服。¥7/月的"全专线"在数学上只能是超售或庞氏。

6.5 社区型信息源

7. 量化评分卡

把"感觉还行"变成可比较的分数。权重按你的画像（日常办公 + 全球多国，不玩游戏）设定。

7.1 计分

加权总分 = Σ(维度得分 × 权重) × 20        // 折算成百分制

示例：
稳定性 4×0.35 = 1.40
带宽   4×0.20 = 0.80
覆盖   3×0.15 = 0.45
纯净度 4×0.15 = 0.60
价格   4×0.10 = 0.40
售后   3×0.05 = 0.15
─────────────────────
合计 3.80 → 76 分

8. 技术架构

理解机场侧怎么搭，才能理解它会在哪里省钱、在哪里出问题。

图 8-1　部署图：机场的技术架构（订阅分发 / 入口 / 跨境 / 落地）

8.1 三个可以省钱的地方

1. 订阅分发：用免费 CDN 隐藏源站，成本几乎为零。这里省钱不影响体验，但意味着订阅链接可能随时换域名。
2. 入口：境内 BGP 入口按带宽月租，是最贵的一环。省这里 = 晚高峰挤。
3. 落地：原生 IP 池比广播 IP 贵一个量级。省这里 = 解锁差、风控高。

所以一家机场的"性价比"本质上是在这三处省哪一处。宣传页不会告诉你，但测速和解锁检测会。

图 8-2　组件图：客户端与订阅/节点之间的组件关系

图 8-3　类图：机场业务的核心数据模型（用户 / 套餐 / 订阅 / 节点 / 落地 IP）

8.2 "全球多国"的真相

判断覆盖，别看宣传页的国家列表，看三个数：

9. 协议怎么选

协议决定"能不能被识别"，线路决定"快不快"。链路质量占七成，协议占三成——但顺序经常被搞反：天天换协议，却不看 mtr。

9.1 正确的组合

选机场时的实际判断：一家机场只提供 SS 或只提供 VMess，说明它没有跟进 2026 年的抗封锁基线；一家机场同时提供 Reality + Hysteria2 + 一个 TCP 老协议，说明它在做容错。后者才是日常办公该选的。

10. 7 天验收 SOP

目标：用 30 元以内、7 天时间，把"感觉"变成"数据"。以下命令在 macOS 终端可直接跑（Windows 用 WSL 或 PowerShell 对应改写）。

10.1 Day 0：准备

1. 装好客户端（见第 11 章），导入订阅，先确认能通。
2. 导出当前订阅配置到本地，作为基线备份：~/.config/clash/config.yaml（Clash Verge Rev 在应用内"导出"）。
3. 建一个记录表（表格或 Markdown），每天记四列：延迟中位数、丢包率、单线程下载、异常时间点。

10.2 Day 1：基线体检（30 分钟）

① 真实节点数——统计订阅里有多少个独立 IP：

python3 - <<'EOF'
import re, collections
cfg = open('/Users/brian/.config/clash/config.yaml').read()
ips = re.findall(r'server:\s*([0-9a-zA-Z\.\-]+)', cfg)
c = collections.Counter(ips)
print(f'节点总数 {len(ips)}　独立 IP {len(c)}　冗余度 {len(c)/max(len(ips),1):.2f}')
for ip, n in c.most_common(10):
    print(f'  {ip:<20} x{n}')
EOF

② 每个 IP 的归属与机房属性：

for ip in $(grep -oE 'server: [0-9a-zA-Z\.\-]+' ~/.config/clash/config.yaml \
            | awk '{print $2}' | sort -u); do
  echo -n "$ip  "
  curl -s "http://ip-api.com/json/$ip?fields=country,city,as,hosting,proxy"
  echo
  sleep 0.5   # 免费接口限速 45 次/分钟
done

③ TCP 可达性（判断是"被封"还是"能用"）：

for ip in $(grep -oE 'server: [0-9a-zA-Z\.\-]+' ~/.config/clash/config.yaml \
            | awk '{print $2}' | sort -u); do
  nc -z -G 3 "$ip" 443 >/dev/null 2>&1 && echo "$ip OK" || echo "$ip FAIL"
done

10.3 Day 2–6：晚高峰连测

每天 21:00–22:00 做四件事，各 2 分钟：

1. 延迟与丢包：ping -c 30 <落地IP>，记中位数与 P95。P95 > 中位数 2 倍 = 抖动大。
2. 单线程下载：Speedtest 单线程，或 curl -o /dev/null -w "%{speed_download}\n" https://speed.cloudflare.com/__down?bytes=100000000。
3. 解锁实测：bash <(curl -L -s https://raw.githubusercontent.com/lmc999/RegionRestrictionCheck/main/check.sh)，只记账号真正在用的那几项。
4. 真实体验：4K 视频拖动进度条，看缓冲圈；ChatGPT 发一条消息，看是否报地区限制。

10.4 挂机监控（可选，但很有用）

# 每 60 秒探一次，追加到日志；跑一晚就能看出断流时段
while true; do
  printf '%s ' "$(date +%H:%M)"
  curl -x http://127.0.0.1:7890 -o /dev/null -s \
       -w '%{http_code} %{time_total}\n' \
       https://www.gstatic.com/generate_204
  sleep 60
done | tee ~/airport-uptime.log

第二天统计：非 204 的行数 ÷ 总行数 = 失败率。可用率 = 1 − 失败率。低于 99% 的，日常办公会明显感知。

10.5 Day 7：结算

1. 算晚高峰衰减率（平峰 vs 21:00 平均值）。
2. 填第 7 章评分卡，算加权总分。
3. 看一眼工单响应：Day 1 提一个技术问题，记录回复时长。
4. 决定：≥80 续费月付；70–79 继续观察；<70 淘汰。

11. 客户端配置

11.1 三端选型

11.2 必须检查的四个设置

1. 开启 TUN / 增强模式：否则部分 App（尤其是命令行、Electron 应用）不走代理。
2. 关闭订阅侧的境外 DoH 依赖：见下方真实案例。
3. 订阅自动更新设 24h：机场换 IP 是常态，不更新会连到已废弃节点。
4. 开启规则分流：国内域名直连。全量走代理会让国内站在晚高峰更慢，还浪费流量。

11.3 订阅安全

• 订阅 URL 里的 token 就是密码。不要贴到群里、不要提交到 Git 仓库。
• 不要用第三方在线"订阅转换"站，它能看到你的全部节点密钥。用本地的 subconverter 或客户端自带转换。
• 换机场后立即删除旧订阅，避免客户端继续向已失联的面板发请求（暴露你的 IP 与使用时间）。

12. 组合方案与预算

"全球多国 + 最稳定"不是一家能给你的，是四层叠出来的。

12.1 主力怎么挑（你的画像）

• 线路：IEPL 优先，优质中转可接受。纯直连不选。
• 覆盖：港 / 日 / 新 / 美 必备，欧洲次之。每地区至少 2 个独立 IP。
• 协议：必须同时提供 VLESS-Reality（TCP 主力）和 Hysteria2 或 TUIC（UDP 备用）。
• 计费：月付，流量 100–300GB 够用（日常办公 + 视频，每月 100GB 上下）。
• 售后：有工单系统，且买前测试 24h 内有回复。

12.2 成本对照

13. 风险与合规

13.1 隐私

• 机场运营方能看到你的目标域名（SNI）、连接时间、流量大小。看到内容需要中间人证书，正常情况下看不到。
• 因此：不要用机场登录银行、主邮箱、公司内网。账号隔离比任何"无日志承诺"都可靠。
• 订阅 token 泄露等于账号被盗用，定期更换。

13.2 支付

• 支付宝/微信有申诉窗口，遇跑路可提交凭证申请冻结商户保证金（成功率不高，但比 USDT 强）。
• USDT/加密货币不可逆，只用于小额试用。
• 付款后立刻检查自动扣款协议：支付宝"设置 → 支付设置 → 免密支付/自动扣款"，微信同理。
• 不在账户里留余额，按需充值。

13.3 合规

13.4 止损清单（跑路后）

1. 关闭自动续费，取消订阅。
2. 截图官网、套餐页、付款记录、客服对话，作为申诉凭证。
3. 立即切换到备用方案（这就是备用层的价值）。
4. 修改与该机场使用相同密码的其他账号。
5. 清理客户端里的旧订阅。

14. 实战操作手册

前面讲的是判断标准，这一章是照着做就能跑完的动作序列。按顺序执行，全程约 2 小时（不含 7 天观察）。

14.1 去哪里买：渠道、候选池、防钓鱼

这一节回答"具体从哪里找"。注意顺序：渠道只负责给你名字，不负责给你结论。所有渠道都有利益关系或噪音，判断仍然靠后面的体检。

四条渠道，各拿各的信息

搜索关键词（直接复制）

机场推荐 IEPL 月付
机场 晚高峰 实测
机场 跑路 2026
Clash 订阅 机场 测评
IEPL 专线 机场 原生IP
机场 按量计费 不过期

搜出来的前几条通常就是榜单站，点进去抄名字即可。不要点带"推广/Sponsored"标记的链接——那才是假官网的高发区。

三步搭候选池

1. 汇总：从 3 家不同榜单站各取前 10 名，去重后得到 20–30 个名字。同一批名字在多个站重复出现，说明它至少还在运营。
2. 初筛（用第 4 章的硬性条件，5 分钟删掉 80%）：
   • 运营 ≥ 2 年（看域名注册时间、TG 频道历史消息）
   • 有月付档，或 1–3 元体验包
   • 官网逐项写了线路类型（哪几个地区是专线）
   • 有工单系统，不是只有机器人
   • 价格算得通：真专线 ≥ ¥25/月、中转 ¥10–30、直连 < ¥10；¥7–8/月 标"IPLC 全专线"直接删
   筛完应剩 5–8 家。
3. 实测：每家买最便宜的月付或体验包（总成本 30–50 元），按 14.7–14.8 跑一遍，最后只留 1 家主力 + 1 家备用，其余全部退订。

候选池（榜单高频出现，非推荐）

以下名字来自榜单站的公开页面，只用来说明"你大概会看到哪些"，我没有逐家实测，不构成推荐：

星岛梦　光速云　二猫云　灵猫网络　飞猫云　微风网络　宇宙云　Firefly　无忧链接　跨界云　闪跃　SOGO云　唯兔云　U1S1　全球云　暮光加速　隐形人　大佬云

防钓鱼：六查

下单七步

1. 独立邮箱注册：不要用主邮箱，更不要用与银行/主账号相同的密码。
2. 选最短周期：最便宜月付，或 1–3 元体验包。首单绝不年付。
3. 付款：支付宝/微信（有申诉窗口）。不要充值余额，不要买"共享/合租"账号——token 共享会被限速或封禁，且没有售后。
4. 立刻关自动扣款：支付宝 → 设置 → 支付设置 → 免密支付/自动扣款；微信同理。截图保存订单号。
5. 存订阅链接：复制到本地加密文件，不要贴群、不要进 Git。
6. 导入客户端：确认后台显示的流量和到期时间正常，异常说明链接格式不对。
7. 马上体检：python3 airport-check.py -c ~/airport.yaml，先看冗余度和 TCP 可达，10 分钟就能淘汰一半。

14.2 开工前准备

14.3 macOS：安装 Clash Verge Rev

1. 打开 github.com/clash-verge-rev/clash-verge-rev/releases，下对应安装包：Apple 芯片选 aarch64.dmg，Intel 选 x64.dmg。
2. 拖进「应用程序」。首次打开若提示"无法验证开发者"：系统设置 → 隐私与安全性 → 找到该应用 → 「仍要打开」。
3. 首次启动后，先只开系统代理（设置 → 系统设置 → 系统代理），不要急着开 TUN。目的是先确认节点通不通。
4. 确认能上网后，再开 TUN 模式（虚拟网卡）。首次开启会要求输入管理员密码安装服务——这是正常的，不开 TUN 的话，终端命令、Docker、部分 Electron 应用不走代理。

14.4 导入订阅

1. 左侧「订阅」→ 右上「新建」→ 粘贴机场给的订阅 URL → 导入。
2. 导入成功后卡片会显示到期时间与已用流量。若显示 0 或报错，说明链接格式不对（见下表）。
3. 右键卡片 → 「更新」，之后建议把自动更新设为每 24 小时。

14.5 iPhone：安装 Shadowrocket

1. 需要一个美区 Apple ID（用礼品卡充值，别用来路不明的共享账号）。App Store 搜 Shadowrocket，约 $2.99。不要搜"小火箭官网"，那类站点大量是假冒的。
2. 打开 App → 右上角 + → 类型选 Subscribe → URL 粘贴订阅链接 → 右上「完成」。
3. 回到首页，点刚导入的那条 → 选择延迟低的节点。
4. 打开顶部开关，首次会提示「添加 VPN 配置」→ 允许，输密码/面容。
5. 「设置 → 延迟测试 → 测试所有节点」，超过 300ms 的直接不用。
6. 全局路由建议选「配置」（按规则分流），不要选「代理」（全量走代理会拖慢国内站）。

14.6 Windows：Clash Verge Rev

1. 同一个项目下 .msi 安装包，装完勾选「TUN 模式」会安装系统服务（需管理员）。
2. 配置复用：在 macOS 端「订阅 → 右键 → 导出」，拿到 YAML 后在 Windows 端「导入本地文件」；或直接填同一条订阅 URL。
3. Windows 上额外检查：防火墙未拦截、系统时间同步、代理未被组策略覆盖。

14.7 第一步体检：跑脚本

脚本 airport-check.py 与本文件同目录，零依赖，macOS 自带 python3 直接跑。

先拿到 config.yaml（三选一）：

• 客户端「订阅」卡片右键 → 编辑/导出，另存为 ~/airport.yaml
• 直接下订阅：curl -L "<你的Clash订阅URL>" -o ~/airport.yaml
• Clash Verge Rev 的 profile 目录（版本不同略有差异）：
  macOS ~/Library/Application Support/io.github.clash-verge-rev.clash-verge-rev/profiles/
  Windows %APPDATA%\io.github.clash-verge-rev.clash-verge-rev\profiles\

# 只做本地统计，不联网（最快，先看是不是虚标）
python3 airport-check.py -c ~/airport.yaml --no-net

# 完整体检：查 ASN + TCP 可达性
python3 airport-check.py -c ~/airport.yaml

# 再加：经 Clash API 测延迟 + 经代理测下载速度
python3 airport-check.py -c ~/airport.yaml --clash-delay --speed

输出怎么读：

14.8 晚高峰实测（连续 5 天）

固定同一个节点、同一个测速源、同一时间段，才有可比性。

1. 时间：20:30–22:30 之间任选 30 分钟，每天同一时段。
2. 客户端里点该节点「延迟测试」，记下 ms。
3. 终端测下载（下面的结果单位是 bytes/s，除以 125000 得到 Mbps）：

curl -x http://127.0.0.1:7890 -o /dev/null -sS \
  -w "耗时 %{time_total}s  速度 %{speed_download} B/s\n" \
  "https://speed.cloudflare.com/__down?bytes=100000000"

4. 同时 ping 落地 IP 30 次，记中位数与 P95：

ping -c 30 <落地IP> | tail -2

记录表模板（抄到本地文件里，每天一行）：

14.9 解锁与 AI 实测

不要只看"全解锁"三个字，逐项点开：

1. 批量检测：bash <(curl -L -s https://raw.githubusercontent.com/lmc999/RegionRestrictionCheck/main/check.sh)
2. Netflix：随便点开一部非自制剧（自制剧全球都能看，没有验证意义）。
3. YouTube：播放 4K 视频 → 右键「统计信息」→ 看 Connection Speed 是否稳定在 20000 Kbps 以上。
4. ChatGPT：网页登录并发一条消息。报 "not available in your country" = IP 不可用；能登录但反复人机验证 = IP 风险分高。

14.10 打分与决策

把 7 天数据填进第 7 章评分卡，按下面的口径落分：

晚高峰衰减率 = (D1 平峰速度 − 5 天晚高峰均速) / D1 平峰速度

< 10%  → 稳定性 5 分
10–15% → 4 分
15–30% → 3 分
> 30%  → 1–2 分

总分 ≥80 续费月付；70–79 继续月付观察；60–69 只当备用；<60 直接淘汰，别再投入时间。

14.11 换机场：无损迁移五步

1. 先接新，不删旧：新订阅导入客户端，旧订阅保持不动。
2. 并行观察 3 天：新节点设为主选，旧节点留在策略组里当备用。
3. 导出备份：把能用的配置另存一份到本地（别只存在机场面板里）。
4. 清理旧订阅：确认新机场稳定后再删。删之前把旧机场后台的订阅链接「重置」一次，防止 token 泄露。
5. 删账号信息：如果用过同密码，改掉。

14.12 故障排查

图 14-1　活动图：上不了网时的排查决策树（从"直连是否正常"开始二分）

14.13 每周 5 分钟运维

1. 更新一次订阅，看节点是否有变化（大规模换 IP 是异常信号）。
2. python3 airport-check.py --no-net，看独立 IP 数有没有骤降。
3. 扫一眼机场公告 / TG 频道：有没有"线路维护""系统升级"连续出现。
4. 检查支付自动扣款列表，确认没有莫名的续费授权。
5. 备份配置：

mkdir -p ~/airport-backup
cp ~/airport.yaml ~/airport-backup/$(date +%F).yaml 2>/dev/null || \
  cp "$HOME/Library/Application Support/io.github.clash-verge-rev.clash-verge-rev/profiles/"*.yaml ~/airport-backup/
ls -lh ~/airport-backup | tail -5

15. 参数与指令速查

15.1 网络诊断命令

15.2 curl 常用参数

15.3 测速与探测 URL

15.4 mihomo / Clash 配置项

最小可用分流规则（放在 rules: 里，从上往下匹配，命中的先赢）：

rules:
  - DOMAIN-SUFFIX,cn,DIRECT
  - DOMAIN-KEYWORD,-cn,DIRECT
  - GEOIP,CN,DIRECT
  - GEOSITE,cn,DIRECT
  - GEOSITE,geolocation-!cn,PROXY
  - MATCH,PROXY

15.5 订阅格式对照

15.6 术语缩写

16. 服务器与终端场景：自研客户端、订阅、proxy config

这一章专门解决一个越来越普遍的问题：机场只给一个"一键客户端"，没有订阅链接。你在 macOS 上点两下能用，但要在云主机、CI、Docker、或者需要 http_proxy 的终端里用，就完全接不上。

16.1 先把问题说清楚：自研客户端到底改变了什么

传统机场卖的是标准协议的节点参数（server / port / 协议 / 密钥），客户端自己实现协议。自研客户端把这一层收走了：节点参数不再暴露给你，客户端内部直接连自己的服务端。

机场为什么这么做：降低小白门槛、控制设备数、防止节点被提取共享、顺便做推广和统计。代价全部转给你：

• 平台受限：Linux 服务器、路由器、CI、Docker 基本用不了。
• 迁移困难：跑路时你没有节点参数，只能跟着重建环境。
• 隐私更多暴露：客户端能上报的东西比一条订阅多得多（设备指纹、使用时长、访问统计）。
• 故障不可排查：出问题你只能看它给的"连接失败"，看不到路由、协议、日志。

16.2 六条判据：这个机场能不能给服务器用

怎么快速验证第 3 条（不用读文档）

# 1. 让客户端正常工作，然后看它监听在哪
lsof -nP -iTCP -sTCP:LISTEN | grep -Ei "clash|mihomo|sing|v2ray|xray|proxy"

# 2. 假设看到了 127.0.0.1:7890，直接测
curl -x http://127.0.0.1:7890 -I -m 10 https://www.google.com

# 3. 看到 200/301 就说明这台机器已经能用了，服务器上的做法同理
#    看到 Connection refused 说明它只在 App 内部转发，没有对外端口

16.3 标准方案：在 Linux 服务器上跑订阅

图 16-1　部署图：服务器上把机场订阅变成 127.0.0.1:7890 的 http/socks 代理

顺序是固定的：订阅 → 内核进程 → 本地端口 → 环境变量 → 各工具。只要端口起来了，剩下的都是标准做法。

方案 A：mihomo（Clash.Meta）命令行 —— 最推荐

优点：直接吃 Clash 订阅，规则、分流、策略组全都能用，和桌面端同一套配置。

# 1. 下载（以 amd64 为例，arm 换 arm64）
cd /tmp
VER=v1.19.0   # 到 github.com/MetaCubeX/mihomo/releases 看最新版
wget https://github.com/MetaCubeX/mihomo/releases/download/${VER}/mihomo-linux-amd64-${VER}.gz
gunzip mihomo-linux-amd64-${VER}.gz
install -m 0755 mihomo-linux-amd64-${VER} /usr/local/bin/mihomo
mihomo -v

# 2. 放配置（把机场的 Clash 订阅下载成 config.yaml）
mkdir -p /etc/mihomo
curl -L "<你的 Clash 订阅 URL>" -o /etc/mihomo/config.yaml
grep -E "^(mixed-port|port|socks-port)" /etc/mihomo/config.yaml   # 确认端口，常见 7890

# 3. 前台试跑，看到 "Start Mixed(http+socks) server" 即成功
mihomo -d /etc/mihomo

# 4. 另开一个终端验证
curl -x http://127.0.0.1:7890 -I -m 10 https://www.google.com

跑通后做成开机自启（systemd）：

cat >/etc/systemd/system/mihomo.service <<'EOF'
[Unit]
Description=mihomo proxy
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=always
RestartSec=3
LimitNOFILE=100000

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable --now mihomo
systemctl status mihomo --no-pager
journalctl -u mihomo -n 30 --no-pager

方案 B：sing-box

# 机场给的 sing-box 订阅（JSON）直接落地
curl -L "<你的 sing-box 订阅 URL>" -o /etc/sing-box/config.json
sing-box check -c /etc/sing-box/config.json     # 先校验
sing-box run  -c /etc/sing-box/config.json      # 前台跑
# inbound 里配置 type=http / socks，listen=127.0.0.1，listen_port=7890

方案 C：xray 单节点（只有节点参数时）

机场不给订阅、但给了 server/port/uuid 时，手写一份最简 VLESS 出站 + socks 入站即可。适合"就一个节点、不用分流"的服务器场景。

方案 D：不装客户端，走网关

如果这台 VM 和你家里/公司网络在同一个内网，最省事的做法是：在路由器或一台常开的机器上跑 mihomo（开 allow-lan），VM 里只需要：

export https_proxy=http://192.168.1.2:7890
export http_proxy=http://192.168.1.2:7890

好处是 VM 上什么都不用装；坏处是跨网段/公网时需要额外做端口与鉴权，不建议把代理端口直接暴露到公网。

16.4 proxy config：环境变量与各工具的配法

这是你提到的重点。绝大多数 Linux 工具只认环境变量或各自的配置文件，不认系统设置面板。

通用环境变量

# 临时生效（当前 shell）
export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export all_proxy=socks5://127.0.0.1:7890     # 部分工具只认这个
export no_proxy="localhost,127.0.0.1,::1,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,169.254.169.254,.internal"

# 取消
unset http_proxy https_proxy all_proxy no_proxy

持久化三选一：

# 只对当前用户
echo 'export https_proxy=http://127.0.0.1:7890' >> ~/.bashrc
echo 'export http_proxy=http://127.0.0.1:7890'  >> ~/.bashrc

# 全局（Debian/Ubuntu 系）
echo 'https_proxy="http://127.0.0.1:7890"' >> /etc/environment

# 只给某个 systemd 服务（推荐，影响面最小）
systemctl edit myapp.service
# 在打开的编辑器里写：
# [Service]
# Environment="https_proxy=http://127.0.0.1:7890" "http_proxy=http://127.0.0.1:7890"

各工具分别怎么配

Docker 用户级配置示例（~/.docker/config.json）：

{
  "proxies": {
    "default": {
      "httpProxy": "http://127.0.0.1:7890",
      "httpsProxy": "http://127.0.0.1:7890",
      "noProxy": "localhost,127.0.0.1,169.254.169.254,10.0.0.0/8,172.16.0.0/12"
    }
  }
}

16.5 只有自研客户端时，还能做什么

1. 先找端口（16.2 第 3 条）。如果客户端在本机起了 7890/1080，那这台机器就能用，把它当本地方案即可；但换到服务器上就得在服务器上再装一次（Linux 版通常没有）。
2. 找它的临时配置。很多"自研客户端"其实是 mihomo / sing-box 的套壳，会把配置写到本地：
   • macOS：~/Library/Application Support/<App>/、~/Library/Containers/<App>/
   • Windows：%APPDATA%\<App>\
   • Linux：~/.config/<App>/
   如果能找到 config.yaml / config.json，里面的节点参数就是标准协议，可以直接搬到服务器。
3. 找"导出 / 二维码 / 分享"入口。少数客户端允许导出节点链接，这是最省事的路径。
4. 问客服要标准订阅。很多机场有订阅，只是默认不展示；直接问"有没有 Clash 或 sing-box 订阅链接，我要在 Linux 服务器上用"。
5. 换机场。如果以上都不行，且你确实需要服务器场景，那这家不适合你——把"提供标准订阅"写进选型条件（第 4 章硬性排除项）。

16.6 案例：小飞象自研客户端（实测拆解）

2026-10 实测的一家：只有自研客户端，官网/面板不给你订阅入口。结论是——配置能提取、能迁到 Linux 服务器，但搬之前必须改 4 个配置项，否则要么用不了，要么把服务器变成公网开放代理。

图 16-2　活动图：自研客户端 → 服务器可用的判定路径

① 客户端结构（先搞清楚它是什么）

只要看到"内核目录里有 config.yaml + 控制器能访问"，基本可以判定：它就是 mihomo/sing-box 的套壳，节点是标准协议，可以搬。

② 第一个坑：端口被占，表现为"proxy 不生效"

症状：客户端显示已连接，但浏览器和终端都上不了网。核心日志里只有这一行：

level=error msg="Start Mixed(http+socks) server error:
  listen tcp 127.0.0.1:7890: bind: address already in use"

原因：机器上还开着老的 ClashX，它占着 7890。新客户端绑不上端口，但 UI 不提示——于是"连上了、却没代理"。

# 定位：谁占着 7890
lsof -nP -iTCP:7890 -sTCP:LISTEN

# 处理：退出占用者（或把新客户端的代理端口改成 7897）
osascript -e 'tell application "ClashX Pro" to quit'

③ 第二个坑：配置里这 4 项不能照搬

其中 allow-lan 最容易被忽略。实测该客户端在 macOS 上确实绑的是 *:7890（局域网可见）；同样的配置放到云主机，就是对全网开放。

④ 节点能不能用：先体检，再搬

用第 10 章的脚本直接读它的 config.yaml：

python3 airport-check.py -c ~/.config/com.vortex.helper/config.yaml

实测输出（节选）：

节点总数 20   独立 IP 3   冗余度 0.15
74.52.13.8     香港/Kwai Chun   AS200772  机房  OK
23.128.188.104 新加坡/Singapore  AS8143    否    OK
23.129.140.178 日本/Tokyo        AS8143    否    OK

国家标注与实际落地不一致：
  ✗ 香港-D5（宣称 香港）→ 实际 新加坡

• 20 个"节点"其实只有 3 台机器（8 + 8 + 4 个端口），冗余度 0.15，一台挂掉 8 个节点一起消失。
• 节点名不可信：香港-D5 落在新加坡；美国-D1~D5 的 server 也在新加坡/日本 IP 上。
• 全部是 ss（chacha20-ietf-poly1305），没有 Reality / Hysteria2，抗封锁能力属最弱一档。

但就"能不能搬"这个问题，答案是能：标准协议 + 标准配置，Linux 上跑 mihomo 直接吃。

⑤ 迁到服务器：只换节点，不动分组

目标机器（tx-vm）上原本已经有一套能跑的结构：

mihomo 监听 172.17.0.1:7890（只对 docker 网桥，公网不可达）
proxy-groups: SG(url-test) / JP(url-test) / OPENROUTER(fallback: JP → SG)
rules: DOMAIN-SUFFIX,openrouter.ai,OPENROUTER  +  MATCH,DIRECT
业务侧: ai-magic-backend 用 ENGINE_PROXY=http://host.docker.internal:7890

但 10 个节点全是旧的（IP 已失效，TCP 探测 FAIL）。做法是保留节点名、只替换 server 和 port——这样三个分组和分流规则一行都不用改：

# 1. 备份
cp /etc/mihomo/config.yaml /etc/mihomo/config.yaml.bak.$(date +%Y%m%d-%H%M%S)

# 2. 校验新配置（mihomo 自带 -t）
mihomo -t -d /etc/mihomo -f /tmp/config.new.yaml

# 3. 生效
cp /tmp/config.new.yaml /etc/mihomo/config.yaml
systemctl restart mihomo && systemctl is-active mihomo

# 4. 回滚（一条命令）
cp /etc/mihomo/config.yaml.bak.20261026-171650 /etc/mihomo/config.yaml
systemctl restart mihomo

实测结果：

⑥ 这类客户端的三条固有风险

1. 凭证明文落盘：vortex.json 里账号、密码、订阅 token 都是明文。任何能读你用户目录的程序都能拿走。
2. IP/端口会轮换：实测几周内就从 23.128.188.93 → .104、23.129.140.130 → .178，端口全换。服务器上的配置会静默失效，业务报错但没人知道原因。
3. 可上报的信息更多：设备指纹、使用时长、访问统计都在客户端手里，比一条订阅多得多。

⑦ 什么时候可以接受自研客户端

16.7 因此，选机场时要多看两条

1. 必须提供标准订阅（Clash / sing-box / V2Ray 任一）。只有自研客户端的，服务器场景直接排除。
2. 节点必须是标准协议。宣传"私有协议 / 自研加速协议"的，基本等于"绑定客户端"，服务器上用不了，也没法用第三方内核做分流。

这两条加进第 4 章的硬性排除，能省掉后面大量的返工。反过来，如果一个机场同时给"一键客户端 + 标准订阅"，说明它对自己的技术栈有信心，也更值得试。

16.8 服务器侧自检清单

17. 速查表

17.1 三分钟判定

17.2 下单前 8 问

1. 月付多少钱？流量多少？倍率多少？（三个数要能算出每 GB 成本）
2. 哪些地区是专线，哪些是直连？（要求文字回答，不看图标）
3. 订阅支持 Clash / sing-box / Shadowrocket 哪几种格式？
4. 同时在线设备数上限？
5. 工单在哪提？平均多久回？（现在提一个试试）
6. 退款政策是什么？
7. 节点用的什么协议？有没有 Reality / Hysteria2？
8. 最近一次换域名是什么时候，怎么通知的？

17.3 三个数字定生死

晚高峰衰减率  < 15%      ← 影响"卡不卡"
独立 IP 数量  ≥ 15       ← 影响"会不会一起死"
7 天可用率    > 99%      ← 影响"能不能当主力"